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Abstract 


The purpose of this presentation on the SNA BIND is to give the audience a direction to pursue when the 
session establishment process fails. An understanding of what the various components do during this 
process is necessary to eliminate wasted tume in determining where the error is. Topics to be discussed will 
include the SNA Access Methods (ACF/VTAM and ACI'/TCAM) and how the BIND is defined, selected, 
and changed in each. Also included is a discussion on the major IBM Subsystems and how they interface 
with the BIND. The conclusion will cover some general steps to be used in tuning and problem determi- 
nation with regard to the BIND. 


Abstract lil 


Preface 


This paper is intended for IBM Systems Engineers, Systems programmers, Network planners and Network 
technicians. 


Special thanks to all of the people who provided information to produce this bulletin. Very special thanks 
go to J. D. Burnside, who helped create this presentation. 
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The topics to be included in this presentation include a brief definition of the BIND and its purpose. In 
order to understand what happens in the session initiation process, it is also necessary to know part of the 
SNA data flow that occurs during that process. Each SNA Access Method has its own requirements 
regarding definition and selection of the BIND. These will be covered, as well as what each access method 
changes in the BIND. Perhaps the most confusing part of the session initiation process is the requirements 
the IBM Subsystems have regarding definition and interface to the access method during the session initi- 
ation process. Most major IBM subsystems will be discussed in that section. Finally some very basic steps 
to be used in tuning and problem determination in the session initiation process will be covered. 
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DEMYSTIFYING THE SNA BIND 


TOPICS 


WHAT IS A BIND 

SESSION INITIATION FLOW 
ACF/VTAM CONSIDERATIONS 
ACF/TCAM V2 CONSIDERATIONS 
SUBSYSTEM CONSIDERATIONS 


TUNING/PROBLEM DETERMINATION 
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A BIND is an SNA request to activate a session between two logical units. The three types of LU to LU 
sessions are: terminal to application program; application program to application program; and terminal to 
terminal. The BIND contains data pertaining to the rules to be used in carrying on the conversation. Also 
contained in the BIND are some characteristics or features that can be used during the session. Both logical 
units must agree to limit their conversation to only those protocols and capabilities that are contained in the 
BIND. There are two types of BINDs currently defined in the Architecture. These are a non-negotiable 
BIND, which is more or less a take it or leave it option, and a negotiable BIND, which can be used, if 
supported by both logical units, to allow the session partners to come to an agreement on the BIND param- 
eters. The details on each byte in the BIND and what it means will not be discussed in this bulletin. That 
level of detail is covered both in the SNA Format and Protocol manual and in the ACF/VTAM Program- 
ming manual. In addition, negotiable BIND will not be discussed in this bulletin. A description of those 
elements in the BIND that can be negotiated is contained in the ACF/VTAM Programming manual. 
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WHAT IS A BIND 


REQUEST TO ACTIVATE A SESSION BETWEEN TWO LOGICAL 
UNITS 


— CONTAINS PARAMETERS SPECIFYING THE PROTOCOLS AND 
DEVICE CHARACTERISTICS TO BE USED 

— BOTH LOGICAL UNITS MUST AGREE AND OBEY 

TWO DIFFERENT BIND TYPES 


— NON-NEGOTIABLE 
— NEGOTIABLE 


REFERENCES 


SC30-3112 SNA FORMAT AND PROTOCOL 
SC30-3339 SNA FORMAT AND PROTOCOL: SNA NETWORK 
INTERCONNECTION 
GC30-3073 SNA TECHNICAL OVERVIEW 
GC20-1869 SNA INTRODUCTION TO SESSIONS BETWEEN LU’S 
GC20-1868 SNA SESSIONS BETWEEN LOGICAL UNITS 
GC27-3136 SNA REFERENCE SUMMARY 
SC27-0449 ACF/VTAM V1R3 PROGRAMMING 
APPENDIX F-SESSION PARAMETERS 
SC27-0611 ACF/VTAM V2 PROGRAMMING 
APPENDIX F-SESSION PARAMETERS 
— §C23-0115 ACF/VTAM V3 PROGRAMMING 
APPENDIX F-SESSION PARAMETERS 
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The session initiation process in ACF/VTAM can begin from three major sources. These sources are as 


follows: 


PLU INITIATED 


SLU INITIATED 


A Primary Logical Unit (PLU) is an application program, residing in a host, that can 
request a session to be initiated by issuing either a ‘SIMLOGON’ (which simulates a 
logon from the secondary LU) or an ‘OPNDST OPTCD=ACQUIRE’ (which 
immediately acquires the secondary LU for a session) to ACF/VTAM. 


A Secondary Logical Unit (SLU) can be a terminal or an application program 
residing in a host or a programmable controller. SLUs can request a session to be 
initiated by issuing the SNA command ‘INIT-SELF’ or an Unformatted Systems Ser- 
vices (USS) LOGON to ACF/VTAM. An application program in a host can issue a 
‘REQSESS’ (request session) to ACF/VTAM if it wants to initiate a session in which 
it will act as the Secondary Logical Unit. 


THIRD PARTY INITIATED 


A session initiation request can be generated from a source other than the intended 
session partners. This can be accomplished by coding LOGAPPL= on the LU, by 
the Network Operator issuing a V NET,LOGON= command to ACF/VTAM, or 
by an application program issuing a “CLSDST OPTCD= PASS’ to ACF/VTAM. 
Using the first two forms will cause ACF/VTAM to initiate the session on behalf of 
the two LU’s. The last method is an application program initiated technique to pass 
an LU from one application to another application without end user involvement. 
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SESSION INITIATION FLOW 


e PLU INITIATED 


— SIMLOGON 
— OPNDST OPTCD= ACQUIRE 


e SLU INITIATED 
— INITSELF 
— USS LOGON 
— REQSESS 
e THIRD PARTY INITIATED 
— LOGAPPL= ON LU 


— V NET,LOGON= BY OPERATOR 
— CLSDST PASS BY PROGRAM 
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Regardless of the technique used to request the session to be initiated, there are common Request Units 
(RUs) that will flow between the System Services Control Points (SSCPs) and the Logical Units involved in 
the process. This is not intended to illustrate all of the flows that can or do occur, rather an attempt to 
point out those RUs that can stop the session initiation process if a negative response is received. One of 
the first RUs that you will see in a trace of this process is a ‘CROSS DOMAIN INITIATE’ (CDINIT). 
You will notice that a CDINIT can flow from primary to secondary or from secondary to pnmary. This is 
because the session initiation request can be PLU initiated or SLU initiated. The primary purpose of the 
CDINIT in the receiving SSCP 1s to resolve the name of the Logical Unit in its domain to a network 
address, establish the availability of that LU (Status, Path, Session Limit), and if the LU in its domain is to 
be the SLU, verify that a Mode Table Entry exists and derive a Class of Service (COS) name if one was not 
specified, or if the LU is to be the PLU, verify that the COS Name is a valid entry in the Class of Service 
Table. Required information is returned in the response to the CDINIT. 


The next RU that is important is the “CROSS DOMAIN CONTROL INITIATE’ (CDCINIT). The 
CDCINIT always flows from the SSCP of the SLU to the SSCP of the PLU. CDCINIT passes informa- 
tion about the SLU, including the BIND image selected. This point is umportant because it shows the the 
Mode Table Entry must come from the SSCP that owns the Secondary Logical Unit. The CDCINIT RU 
requests the SSCP of the PLU to send a ‘CONTROL INITIATE’ (CINIT) to the Primary Logical Unit. 
The CINIT informs the PLU of the new session request. 


The CINIT causes the Logon Exit of the application to be driven requesting that the application program 
issue an ‘OPNDST OPTCD= ACCEPT’ to initiate the session. If the application program wants to see the 
session parameters supplied from the Mode Table Entry, it must issue an ‘INQUIRE 
OPTCD=SESSPARM’ pnor to the “OPNDST’. The application can use these session parameters, part of 
them, or none of them in establishing the session. If the application decides not to establish the session it 
will issue a “CLSDST’ to ACF/VTAM. 


When the application issues the "OPNDST’ it points to an area that contains the session parameters it wants 
included in the BIND. The content of this area is under control of the application, however, some fields are 
modified by the SSCP. The BIND 1s sent by ACF/VTAM as a result of the ‘OPNDST” being issued. The 
Secondary Logical Unit can either accept the BIND (+ RSP) or reject the BIND (-RSP). 
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SESSION INITIATION FLOW 
PLU SSCP(PLU) SSCP(SLU) SLU 


CDINIT 
+RSP 
CDCINIT 
(CONTAINS BIND DATA) 
+RSP 
CINIT 
(CONTAINS BIND DATA) 
+RSP 
BIND 
+RSP 
e NOTES 


— BIND IMAGE (MODE TABLE ENTRY) ALWAYS COMES FROM 
THE SSCP OF THE SLU 

— COS TABLE ENTRY NAME COMES FROM THE SSCP OF SLU 
BUT THE VR LIST IS OBTAINED FROM THE SSCP OF THE PLU 
(ACF ViR3 AND ABOVE - MAY ALSO COME FROM GATEWAY 
SSCP FOR CROSS NETWORK SESSIONS WITH ACF/VTAM V2R2 
AND V3) 

— APPLICATION MUST ISSUE ‘INQUIRE OPTCD=SESSPARM’ TO 
SEE THE CINIT (BIND DATA) BUT THIS IS NOT REQUIRED 

— BIND ISSUED AS A RESULT OF ’OPNDST’ COMES FROM THE 
APPLICATION AND CAN BE CHANGED BY THE APPLICATION 
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Two concepts that should be understood from both a session initiation and a tuning standpoint is that of 
SNA chaining and segmentation. Chaining can occur both outbound from the application or ACF/VTAM 
V2 or V3, and inbound from the Secondary Logical Unit. Outbound chaining is a application program or 
application program invoked function that must be supported by the SLU. Some devices support only 
single outbound chain elements. Inbound chaining 1s dependent on the device, however the application 
must support assembly of chain elements or processing of each element as it arrives. The maximum size of 
each chain element 1s indicated in the BIND in the MAXRU field. Both maximum inbound and outbound 
RU sizes are specified. 


Outbound segmentation is accomplished independently of the application. The application sends the 
maximum outbound RU and when it 1s received by the boundary function (BF, which 1s either the 
ACF/NCP or ACF/VTAM where the SLU is physically attached), it is broken into segments. This function 
must be supported by the SLU. The maximum size of each segment is determined by the definition of the 
SLU (PU MAXDATA =) and the ACF/NCP (BUILD BFRS= ) parameters. 


8mm ACF/VTAM will also perform segmentation for channel attached SNA control units (such as the 
3274). This support works just like ACF/NCP’s, and is controlled by the MAXDATA parameter on the 
PU macro. 


Inbound segmentation is performed by the SLU independently of the application. The SLU sends the seg- 
ments to its BF, and the segments are sent, in tact, to the SSCP of the PLU. The SSCP will reassemble the 
inbound segments and then forward the assembled data to the application program (NOTE: ACF/VTAM 
V2 and V3 for MVS/370 uses LSQA, subpool 229, in the application program’s address space for the seg- 
mentation assembly area. ACF/VTAM V3 for MVS/XA uses extended LSQA for this purpose). 
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SNA CHAINING/SEGMENTATION 


CHAINING 
— QUTBOUND CHAINING 
— APPLICATION PROGRAM FUNCTION MUST BE SUPPORTED 
BY THE SLU 
— ACF/VTAM V2 AND V3 CAN PERFORM CHAINING VIA LMPEO 
OPTION ON BEHALF OF THE APPLICATION 
— INBOUND CHAINING 


— DEPENDENT ON THE DEVICE 


— SIZE OF CHAIN ELEMENT BASED ON MAXIMUM RU SIZE IN 
BIND 


SEGMENTATION 


— APPLICATION PROGRAM INDEPENDENT 


DONE BY THE BOUNDARY FUNCTION(BF) OR SLU 


MUST BE SUPPORTED BY THE SLU 


SIZE OF SEGMENT BASED ON NCP OR VTAM PU MAXDATA= 
PARAMETER AND NCP BUFFER SIZE 
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This foil contains examples of both chaining and segmentation. From a host performance standpoint, seg- 
mentation is preferable since the application has to issue only one ‘SEND’ to get the data out, as opposed to 
multiple chain elements, which require multiple ‘SEND’s to be issued. This is not true if the application 
program is executing under the control of ACF/VTAM V2 or V3, and has implemented support for the 
Large Message Processing Enhancement Option (LMPEO). This facility allows the application program, 
when in session with an SNA LU, to issue one ‘SEND’ to ACF/VTAM, and lets ACF/VTAM perform all 
necessary chaining. Outbound segmentation is accomplished in the ACF/NCP, and thus requires both 
buffers and 37x5 utilization to get the entire RU to its destination. Inbound segmentation is accomplished 
by the SLU and reassembled in the host by ACF/VTAM. It is valid, and many devices support, both 
chaining and segmentation. 


NOTE: The abbreviations on the foil are: 
OIC - Only In Chain 
FIC - First In Chain 
MIC - Middle In Chain 
LIC - Last In Chain 
OIS - Only In Segment 
FIS - Furst In Segment 
MIS - Middle In Segment 
LIS - Last In Segment 
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PLU SSCP BF SLU 


OUTBOUND CHAINING 


SEND (FIC) 
SEND (MIC) 
SEND (MIC) 
SEND (LIC) 


INBOUND CHAINING 


SEND (FIC) 
SEND (MIC 


SEND (LIC) 


OUTBOUND SEGMENTATION 


SEND (OIC) 
SEND (FIS) 
SEND (MIS) 
SEND (LIS) 


INBOUND SEGMENTATION 


SEND (FIS) 
SEND (MIS) 
SEND (LIS) 


COMBINATION OF CHAINING AND SEGMENTATION IS VALID 
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The first SNA Access Method we will discuss is ACF/VTAM. The items that will be covered will be how a 
BIND is defined to ACF/VTAM, how the BIND image 1s selected by ACF/VTAM, what fields in the 


BIND are changed by ACF/VTAM, and what portions of the BIND are checked by ACF/VTAM for 
Non-SNA 3270s. 
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ACF/VTAM CONSIDERATIONS 


HOW TO DEFINE A BIND 
HOW THE BIND IMAGE IS SELECTED 
WHAT VTAM CHANGES 


NON-SNA 3270 BIND CHECKING 
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There are three macros furnished with ACF/VTAM to be used to generate BIND images. The MODETAB 
macro is used to indicate the start of a Mode Table. The label on this macro is used to indicate the CSECT 
name for this particular table. In ACF/VTAM you can have as many different Mode Tables as are needed 
to suit your installation requirements. When you define an LU, you can indicate which Mode Table to use 
with this particular LU through the MODETAB= parameter. The same Mode Table can be used by many 
LUs. ACF/VTAM also comes with a default Mode Table, ISTINCLM (ISTINALM in OS/VS1). The 
IBM supplied table contains entries that are valid for most IBM devices and subsystems. 


The MODEENT macro is used to actually define a BIND image. The entry name is indicated by the 
LOGMODE= keyword. The other parameters are included here for reference later in this presentation, 
however no further details will be provided because each 1s documented 1n the references listed. The 
MODEENT macro can have a label, and it 1s recommended that the label be the same as the | 
LOGMODE= parameter. This could be helpful if you ever have to look at the code that 1s generated by 
the macros. One Mode Table can have multiple MODEENT macros specified. 


The MODEEND macro is the final macro, and it is used to indicate the end of the table. 
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ACF/VTAM BIND GENERATION 


MODETAB 
MODEENT 


MODEEND 


e REFERENCES 


LOGMODE = 
TYPE= 
FMPROF = 
TSPROF = 
PRIPROT = 
SECPROT= 
COMPROT= 
RUSIZES = 
PSERVIC = 
PSNDPAC = 
SRCVPAC = 
SSNDPAC = 
COSNAME = 
ENCR= 


ENTRY NAME 
NEGOTIABLE? 

FM PROFILE 

TS PROFILE 

PLU PROTOCOL 

SLU PROTOCOL 
COMMON PROTOCOL 
INBOUND/OUTBOUND 
SLU PRES SRVCS 

PS PACING 

SR PACING 

SS PACING 

CLASS OF SERVICE 
ENCRYPTION 


SC27-0584 ACF/VTAM PLANNING AND INSTALLATION 


VERSION 1 RELEASE 3 


SC27-0610 ACF/VTAM PLANNING AND INSTALLATION 


VERSION 2 RELEASE 1 


$C27-0613 ACF/VTAM CUSTOMIZATION 


VERSION 2 RELEASE 2 


$C23-0112 ACF/VTAM CUSTOMIZATION 


VERSION 3 
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The BIND selection algorithm in ACF/VTAM is fairly straight forward. It is primarily dependent on 
whether or not the initiate RU (INIT’) contains a Mode Table Entry name, and whether or not a default 
entry may be selected. If the ‘INIT’ RU has a non-blank Mode Table Entry name, that is the “INIT-SELF’ 
contains an entry name or the USS Logon contains a LOGMODE parameter (either by the user entering 
this parameter or having a default mode entry name defined in the USS table), ACF/WTAM will search first 
the table specified by the user, and second the default table. If the entry is not found the ‘INIT’ is rejected, 
and the session setup fails. 


If the INIT’ does not contain a Mode Table Entry name, ACF/VTAM will first see if the user has specified 
a default entry (DLOGMOD =) to use. If a default is specified ACF/VITAM will search the user table (if 
specified) and then the system table. If the entry 1s not found, the “INIT” is rejected, and the session setup 
fails. If the user has not specified a default entry, ACF/VTAM will select the first entry in the user table (if 
coded), or the first entry in the system table (which is valid for an SNA 3767). 
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ACF/VTAM BIND SELECTION 


e IF ‘INIT’ RU HAS NON-BLANK MODE NAME 


— IF ENTRY CONTAINED IN USER TABLE (MODETAB=), THEN 
USE IT ELSE 


— IF ENTRY IN SYSTEM TABLE (ISTINCLM) USE IT ELSE 
— REJECT THE ‘INIT’ 
e IF ‘INIT’ RU HAS NO MODE NAME 


— IF DLOGMOD= CODED, SEARCH USER TABLE, THEN SYSTEM 
TABLE IF NOT FOUND REJECT ’INIT’ 


— IF DLOGMOD= NOT CODED, USE FIRST ENTRY IN USER 
TABLE (IF CODED) OR SYSTEM TABLE 
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The only parameters in the BIND that ACF/VTAM will override are the pacing parameters. Lets start by 
defining the types of pacing implemented in ACF/VTAM, and how they can be specified by the user. 


Outbound pacing in ACF/VTAM is in two-stages. The first stage is pacing from ACF/VTAM to the 
Boundary Function (BF), and this is called Primary Send or PS pacing. 


The second stage of outbound pacing is called Secondary Receive or SR pacing. This is pacing from the 
boundary function to the Secondary Logical Unit. 


While the Architecture has defined two stage inbound pacing, only single stage inbound pacing has been 
implemented in current SNA products. Inbound pacing is a function that requires device support in the 
Secondary Logical Unit. Inbound pacing consists of Secondary Send or SS pacing and Primary Receive or 
PR pacing. In SNA today, Primary Receive and Secondary Send pacing are always equal. 


The pacing parameters are defined by the user, either through the Mode Table or the definition of the 
Logical Unit. On the LU macro, the user can code VPACING, which equates to Primary Send, and 
PACING, which equates to Secondary Receive. On the APPL statement the user can code VPACING, 
which equates to inbound pacing (Primary Receive and Secondary Send) if the APPL will be the PLU in 
this session. To use primary send (PS) pacing you must not code AUTH = NVPACE on the APPL 
(AUTH= VPACE 1s the default). If the APPL is to act as the Secondary Logical Unit in this session, then 
VPACING becomes the Primary Send pacing count and there is no Secondary Receive. 


The user may also specify pacing in the Mode Table Entry by using the keywords that are supplied. You 


will note that there is no keyword for Primary Receive. This is because inbound pacing is single stage only 
and Primary Receive and Secondary Send must be equal. 
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ACF/VTAM BIND CHANGES 


e PACING 
SSCP(PLU) BF SLU 


OUTBOUND PACING (TWO STAGE) 
PRIMARY SEND (PS) 


SECONDARY RECEIVE (SR) 
INBOUND PACING (SINGLE STAGE) 
PRIMARY RECEIVE (PR) SECONDARY SEND (SS) | 
e USER CODED PARAMETERS AFFECT PACING 
— LU VPACING =,PACING = 
— APPL VPACING = ,AUTH=NVPACE 
— MODEENT PSNDPAC = 


SRCVPAC = 
SSNDPAC = 
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Now that we’ve reviewed how pacing is defined, lets see how these parameters can be overridden by 
ACF/VTAM. 


If the Primary LU does not support pacing, then the Primary Send pacing 1s set to zero. Otherwise, if 
Primary Send pacing is not zero in the Mode Table Entry selected, it is used. Otherwise ACF/VTAM will 
use VPACING from the definition of the SLU. 


If Secondary Receive pacing for ACF/NCP supported LU’s is not zero in the Mode Table Entry selected, it 
is used. Otherwise ACF/VTAM will use PACING from the definition of the SLU. 


If Secondary Receive pacing for application to application sessions or for local SNA devices is not zero in 
the Mode Table Entry selected, it is used. Otherwise, if the Primary application does not allow pacing, then 
set the Secondary Receive pacing to zero. Otherwise, ACF/VTAM will use VPACING from the definition 
of the SLU. | 


Please note the change in override critena for inbound pacing. If the Mode Table Entry for Secondary Send 
pacing is not zero, use the VPACING from the Primary APPL, otherwise use zero. This change 1s neces- 
sary to allow an application to use inbound pacing for some sessions and still work for sessions that do not 
support that function. 
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ACF/VTAM PACING 


PRIMARY SEND PACING 


— IF PLU AUTH=NVPACE USE ZERO ELSE IF PSNDPAC= IS NOT 
ZERO USE IT ELSE USE VPACING FROM SLU 


SECONDARY RECEIVE PACING (NCP LU) 


— IF SRCVPAC= IS NOT ZERO USE IT ELSE USE PACING FROM 
SLU 


SECONDARY RECEIVE PACING (APPL TO APPL OR LOCAL SNA) 


— IF SRCVPAC= IS NOT ZERO USE IT ELSE IF PLU 
AUTH=NVPACE USE ZERO ELSE USE VPACING FROM SLU 


INBOUND PACING 


— IF SSNDPAC= IS NOT ZERO USE VPACING FROM PLU ELSE 
USE ZERO 
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Lets look at some examples of how pacing is finally resolved in the BIND, depending on how the user has 
coded various parameters and the Mode Table Entry. You will note that in each case for outbound pacing 
the Mode Table Entry parameter is used unless it 1s zero. If it is zero, then the appropriate definition is 
used. If both are zero, then the BIND will contain zero. 


For inbound pacing the Mode Table Entry really only indicates whether or not the device supports inbound 


pacing. The value used in the BIND will always be either zero or what is coded on the APPL for 
VPACING. 
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WHERE 
CODED 


LU 
LU 


LU 
LU 


APPL 
APPL 
APPL 


ACF/VTAM PACING 


ACF/VTAM 
PARAMETER 


~VPACING=A 


VPACING=A 


PACING=C 
PACING=C 


VPACING =F 
VPACING =F 
VPACING=0 


MODEENT 
PARAMETER 


PSNDPAC=B 
PSNDPAC =0 


SRCVPAC=D 
SRCVPAC =0 


SSNDPAC=E 
SSNDPAC =0 
SSNDPAC=E 


BIND 
SENT 


PS=B 
PS=A 


SR=D 
SR=C 


PR=SS=F 
PR=SS=0 
PR=SS=0 
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ACF/VTAM will respond to any BIND that is destined for a Non-SNA 3270. The fields in the BIND that 
are checked by ACF/VTAM are indicated on this fol. ACF/VTAM will reject the BIND if the values 
shown here are not present. 
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ACF/VTAM NON-SNA 3270 


MUST BE NON-NEGOTIABLE 
FM AND TS PROFILE MUST BE ’02’ 
PRIMARY PROTOCOL 


— SINGLE REQUEST CHAINS 
— NO COMPRESSION 


SECONDARY PROTOCOL 


— SINGLE REQUEST CHAINS 
— MULTIPLE OUTSTANDING CHAINS (DELAYED REQUEST MODE) 
— SECONDARY NO RESPONSE MODE 


COMMON PROTOCOLS 


— NO FM HEADERS 

— FDX CONTENTION 

— PLU HANDLES RECOVERY 

— SLU WINS CONTENTION 

— EITHER BRACKETS NOT USED 
OR 
PRIMARY SENDS END BRACKET 
UNCONDITIONAL END BRACKET 
SECONDARY FIRST SPEAKER 


IF NOT ALL ABOVE REJECT THE ’INIT’ 
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For ACF/TCAM V2 we will review how a BIND is defined (There are differences between ACF/VTAM 
and ACF/TCAM in this area), how ACF/TCAM selects the BIND image to be used, and what values 
ACF/TCAM changes and enforces in the BIND. What will be discussed will be limited in some parts to 
what ACF/TCAM does when it is acting as the Primary Logical Unit (i.e. when the DCB interface is being 
used). The Subsystem Interface will be covered later when we discuss what each Subsystem does with the 
BIND, as this is common between the Access Methods when the Subsystem Interface (ACB Interface) 1s 
being used. 
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ACF/TCAM V2 CONSIDERATIONS 


e HOW TO DEFINE A BIND 
e HOW THE BIND IMAGE IS SELECTED 


e WHAT TCAM CHANGES 
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One of the major differences in this area between the SNA Access Methods 1s that in ACF/TCAM V2 there 
is only one Mode Table for the system. In ACF/TCAM it 1s referred to as the BIND Table (or BIND 
Image table). ACF/TCAM also furnishes three macros to generate its BIND Table. Only the keywords on 
each of these macros and parameters that are common to both SNA access methods are shown. 


The first of these macros is IEDBTAB. This macro 1s used to indicate the start of the BIND Table. The 
label on this macro must be IEDBITN. The keyword DEFBI= is used to indicate which entry in the table 
is the default system entry. 


The IEDBENT macro is used much the same as the MODEENT macro in ACF/VTAM. Again these will 
not be covered in detail for each of these keywords and their usage. The main difference between 
ACF/VTAM and ACF/TCAM is that the BIND Table entry name generated by ACF/TCAM 1s the label 
of the IEDBENT macro, where in ACF/VTAM the user specified the name of the entry through the 
LOGMODE= keyword. 


The IEDBEND macro is used to indicate the end of the table. 
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ACF/TCAM V2 BIND GENERATION 


IEDBTAB CBI= SUPPLIED 
DEFBI= DEFAULT 

IEDBENT FMTYPE= NEGOTIABLE? 
FMPROF = FM PROFILE 
TSPROF = TS PROFILE 
PRIPROT = PLU PROTOCOL 
SECPROT = SLU PROTOCOL 
COMPROT= COMMON PROTOCOL 
LUPROF= LU TYPE 
TSUSAGE = RU SIZES,PACING 
PRESERC = LU PRES SRVCS 
COS= CLASS OF SERVICE 
CRPTOPT= NCRYPTION 
LOGON= OGON DATA 
USRDATA= USER DATA 

IEDBEND 


® REFERENCES 


$C30-3153 ACF/TCAM VERSION 2 NETWORKING 
INSTALLATION GUIDE 

$C30-3132 ACF/TCAM VERSION 2 BASE 
INSTALLATION GUIDE 
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The BIND selection cnteria used by ACF/TCAM 1s very similar to the technique used by ACF/VTAM. 
The primary difference is that ACF/TCAM does not have a user table to search. 


Again, the primary criteria is whether or not the “INIT” RU contains a non-blank Mode Table Entry name. 
If the ‘INIT’ has a non-blank mode name, the BIND Table 1s searched for the entry. If the entry 1s found it 
is used. If it is not found the “INIT” is rejected, and the session setup fails. 


If the ‘INIT’ RU has no Mode Table Entry name, then ACF/TCAM will check to see if the user has speci- 
fied the IEDLMODE option field for that LU. If the field has been specified then ACF/TCAM will use 
that name to search the BIND Table. If the entry is not found the ‘INIT’ 1s rejected, and the session setup 
fails. If the IEDLMODE option field has not been coded by the user then ACF/TCAM will use the system 
default entry specified by the user when the BIND Table was generated. 
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ACF/TCAM BIND SELECTION 


IF ‘INIT’ RU HAS NON-BLANK MODE NAME 

— IF ENTRY IN BIND TABLE (IEDBITN) USE IT ELSE 
— REJECT THE ‘INIT’ 

IF ‘INIT’ RU HAS NO MODE NAME 


— IF IEDLMODE OPTION FIELD CODED FOR THIS LU THEN USE 
THAT NAME IF NOT FOUND REJECT ‘INIT’ 


— IF IEDLMODE OPTION FIELD NOT CODED USE DEFAULT ENTRY 
IN BIND TABLE (IEDBTAB DEFBI=) 
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In discussing what ACF/TCAM V2 changes in the BIND, only those items ACF/TCAM changes when it is 
acting as the Primary Logical Unit are mentioned. 


Three items are changed by ACF/TCAM in the BIND, regardless of what is specified. These items are that 
ACF/TCAM will only operate in ‘immediate request mode’ and requires ‘primary chain response protocol’. 
ACF/TCAM also requires that the secondary is the first speaker. 


ACEF/TCAM wil also enforce certain protocols regardless of the Device Message Handler (DMH). These 


are that ACF/TCAM will insure that end bracket is sent, 1f required, and it will not allow brackets if they are 
not to be used. ACF/TCAM will also enforce the bracket termination rules. 
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ACF/TCAM V2 BIND CHANGES 


e PRIMARY LU PROTOCOL 


— IMMEDIATE REQUEST MODE 
— PRIMARY CHAIN RESPONSE PROTOCOL 
— COMMON LU PROTOCOL 


e SECONDARY FIRST SPEAKER 


— ENFORCED BY TCAM IF SET 

— PRIMARY LU PROTOCOL 
IF PRIMARY DOES NOT SEND END BRACKET 
TCAM WILL ENSURE THAT NO END BRACKET 
IS SENT REGARDLESS OF WHAT IS SET IN 
THE DMH 

— COMMON LU PROTOCOL 
IF BRACKETS ARE NOT USED TCAM DOES 
NOT PERMIT THE IEDRH MACRO IN THE 
PLU DMH TO SET BRACKETS IN THE RH 
BRACKET TERMINATION RULE IS ENFORCED 


e IF TCAM IS TO BE THE SLU IN A SESSION SEE “ACF/TCAM 


VERSION 2 NETWORKING INSTALLATION GUIDE’ (SC30-3153) 
SECTION 3 
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The Subsystems are perhaps the key part of this bulletin because, as you have seen, the actual content, with 
very few exceptions, of the BIND is totally up to the Subsystem. As we discuss these various IBM Subsys- 
tems you will see that each has its own requirements 1n the session initiation process. This is not an attempt 
to educate you in the Subsystem/Access Method interface, rather an attempt to give you a good direction to 
pursue when the session initiation process fails. If you are attempting to resolve why you got a SESSION 
NOT BOUND’, an understanding of what the Subsystem does in this process can be very time saving in the 
resolution of the problem. This discussion will apply to both ACF/VTAM and ACF/TCAM V2 when the 
Subsystem Interface is being used. Remember that TSO, NCCF, RES, and ACF/TCAM V3 are not sup- 
ported through this interface. Also, since ACF/TCAM is not supported on VSE, the POWER/VS consider- 
ations are applicable only in an ACF/VTAM environment. 
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SUBSYSTEM CONSIDERATIONS 


CICS/VS V1R6 
CICS/VS V1R7 
IMS/VS 
TSO/VTAM 
NCCF 
ES2/RJE 

JES3 
POWER/VS 
RES 

BDT 


ACF/TCAM V3 
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Remember from earlier that the application program must issue an ‘INQUIRE’ to see the session parameters 
that have been selected for this session. CICS/VS does not issue an ‘INQUIRE’. This means that regardless _ 
of what you have coded in the Mode Table Entry, it will have no effect (other than pacing). (NOTE: There 
is One exception to this, and this is controlled by the LOGMODE parameter. See this description on the 
next foil). CICS/VS will create the BIND image based on parameters coded when the CICS/VS Terminal 
Control Table (TCT) was generated. CICS/VS does have some excellent references, by device type, to assist 
in how to define the device to CICS/VS. 
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CICS/VS V1R6 CONSIDERATIONS 


CICS/VS DOES NOT ISSUE ‘INQUIRE’ 
BIND VALUES USED ARE BASED ON CICS TCT GEN PARAMETERS 
PACING OVERRIDDEN BY VTAM 
REFERENCES 
$C33-0149 CICS/VS RESOURCE DEFINITION GUIDE 
$C33-0096 CICS/VS IBM 3270/8775 GUIDE 
$C33-0072 CICS/VS IBM 4700/3600/3630 GUIDE 
$C33-0073 CICS/VS IBM 3650/3680 GUIDE 


$C33-0074 CICS/VS IBM 3767/3770/6670 GUIDE 
$C33-0075 CICS/VS IBM 3790/3730/8100 GUIDE 
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The primary CICS/VS TCT parameters that affect the BIND are contained on this page. Remember that 
CICS/VS V1R6 requires that the LU be defined in the TCT before a session can be established. If you ever 
have a problem with session establishment, one of the first things you should do is to vernfy that the LU is 
defined in the TCT. 


The TRMTYPE= parameter is used to select most of the protocols to be selected for this session. What is 
illustrated here is the different ways to specify 3270 type devices, a common coding error in CICS/VS. 
Remember that a Non-SNA 3270 is always an LU Type 0, while an SNA 3270 1s always either an LU’ Type 
2 for a display, or an LU Type 1 or 3 for a pmnter. 


The BUFFER = parameter will be used by CICS/VS to determine the maximum outbound RU size that 
can be used. A common error made here is to specify too small a value. If the value coded is too small you 
might not see any indication of it until the ‘CPU starts having performance problems. Remember that the 
application must perform the chaining if the message is larger that MAXRU outbound. In CICS/VS VIR6 
and above, a new facility has been implemented to exploit new capabilities in ACF/VTAM V2 and V3. 
CICS/VS has implemented support for ACF/VTAM’s Large Message Processing Enhancement Option 
(LMPEO). This eliminates the necessity for CICS/VS to perform any outbound chaining for its sessions 
with SNA LU’s. ACF/VTAM will perform this function on CICS/VS’s behalf. 


The RUSIZE= parameter in the TCT will be used to determine the maximum inbound RU size. This will 
be the maximum size chain element sent from the SLU. 


The parameters TRMMODL=, DEFSCRN=, ALTSCRN=, and FEATURE= all can affect what is in 
the PSERVIC portion of the BIND. The FEATURE= parameters are used to indicate extended data 
stream support for SNA 3270s. Extended data streams are used to support graphics data (e.g. full seven 
color and programmed symbol support). 


One keyword in the TCT should be used with caution. The LOGMODE= keyword causes CICS/VS to 
issue an “OPNDST’ to ACF/VTAM, but rather than pointing to an area containing the BIND image to be 
used, it indicates which Mode Table Entry to use. This 1s not valid and will be rejected if the resource is 
cross domain or cross network. As a result, this parameter should be left off, or be set to blanks. Also, 
since CICS/VS does not issue an ‘INQUIRE’ to find out the session parameters, the user must insure that 
the TCT parameters are compatible with the Mode Table Entry used. 


There is one other way this parameter can be set. If LOGMODE= 0 is coded, CICS will not build the 
BIND from the TCT parameters, but will use whatever parameters are specified in the SLU’s Mode Table 
entry. These parameters need to be consistent with the TCT settings or communication on the session may 
not be possible. 
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CICS/VS V1R6 TCT PARAMETERS 


NETNAME = 

TRMTYPE= 3270 
3270P 
TWX 
LUTYPE2 
LUTYPE3 
SCSPRT 


BUFFER= 
RUSIZE = 
TRMMODL= 
DEFSCRN= 
ALTSCRN= 
FEATURE = 


LOGMODE= 


REQUIRED 
NON-SNA DISPLAY 
NON-SNA PRINTER 
NTO TWX 

SNA DISPLAY 

SNA PRINTER(DSC) 
SNA PRINTER(LU1) 


MAXRU OUTBOUND 


MAXRU INBOUND 


ALL AFFECT THE 
PSERVIC 


NOT VALID FOR 
CROSS DOMAIN OR 
CROSS NETWORK 
RESOURCES 
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CICS/VS V1R7 works just like VIR6 if the SLU is predefined in the TCT at CICS/VS generation. 


One of the major enhancements of CICS/VS V1R7 is to allow dynamic terminal definitions. This is 
supported only for sessions that are SLU initiated. If this feature is utilized, then the TCT definition will be 
dynamically built when the CICS/VS Logon exit is invoked. CICS/VS will interrogate the CINIT RU 
passed from ACF/VTAM. From this RU, CICS/VS will obtain the LU name, and will interrogate the 
session parameters and then search the predefined model definitions to obtain a matching definition. A user 
exit is then invoked so the user can supply the CICS/VS terminal ID. Upon return from the exit, the 
terminal is then added to the other TCT entries, and the session setup proceeds. 
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CICS/VS ViR7 CONSIDERATIONS 


JUST LIKE V1R6 IF SLU IS PRE-DEFINED 


SUPPORTS DYNAMIC SLU DEFINITIONS IF SESSION IS SLU 


INITIATED 


LU NAME AND SESSION PARAMETERS OBTAINED FROM CINIT 


SER EXIT ALLOWS USER SPECIFIED TERMINAL ID 


PACING OVERRIDDEN BY VTAM 


REFERENCES 


$C33-0149 
$C33-0096 
$C33-0072 
$C33-0073 
$C33-0074 
$C33-0075 


CICS/VS RESOURCE DEFINITION GUIDE 
CICS/VS IBM 3270/8775 GUIDE 

CICS/VS IBM 4700/3600/3630 GUIDE 
CICS/VS IBM 3650/3680 GUIDE 

CICS/VS IBM 3767/3770/6670 GUIDE 
CICS/VS IBM 3790/3730/8100 GUIDE 
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IMS/VS does issue an ‘INQUIRE’ to ACF/VTAM and uses most of the parameters specified in the Mode 
Table Entry. As with CICS/VS the terminal must be defined to IMS/VS before a session can be established. 
The first thing to do if a session 1s not established is to insure that the LU 1s defined to IMS/VS. 


The only parts of the BIND overridden by IMS/VS are the RU sizes and the protocols. IMS/VS will use 
the OUTBUF= parameter on the TERMINAL definition to determine the maximum outbound RU size. 
It will also use the COMM RECANY = parameter to replace the maximum inbound RU size. The 
primary, secondary, and common protocols will be set based on device or LU type. Remember that 
ACF/VTAM can still overnde the pacing. 


The TERMINAL macro also has a MODETBL= parameter that can be used to select a Mode Table Entry 
to be used in this session. Since IMS/VS does issue an ‘INQUIRE’ you do not have to correlate the Mode 
Table Entry to other parameters in IMS/VS. The RU sizes will still be overridden, however the parameter 1s 
not valid if the resource is cross domain or cross network. 
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IMS/VS CONSIDERATIONS 


IMS/VS DOES ISSUE ‘INQUIRE’ 
TERMINAL NAME= REQUIRED 
RUSIZES IN BIND OVERRIDDEN 


— TERMINAL OUTBUF= REPLACES MAXRU OUTBOUND 
— COMM RECANY= REPLACES MAXRU INBOUND 


PRIPROT, SECPROT AND COMPROT SET BASED ON LU TYPE 


TERMINAL MODETBL= CANNOT BE USED IF RESOURCE IS 
CROSS DOMAIN 


REFERENCES 


SH20-9081 IMS/VS VERSION 1 INSTALLATION GUIDE 

SH20-9054 IMS/VS VERSION 1 PROGRAMMERS GUIDE 
FOR REMOTE SNA SYSTEMS 

SH20-0911 IMS/VS VERSION 2 SYSTEMS PROGRAMMING 
REFERENCE MANUAL 
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TSO does issue an ‘INQUIRE’ to determine the session parameters, however it only uses certain of the 
parameters. If the Function Management Profile 1s set to ‘02’ then TSO assumes that the device is a 
Non-SNA 3270. Otherwise TSO will look at the first byte in the PSERVIC to see if the device is an LU 
Type 2 (SNA 3270). If neither of these conditions are true, then TSO assumes that the device is an LU 
Type 1. | 


The entire BIND 1s ‘hardcoded’ in TSO/VTAM except: 


1. Ifthe device is an LU Type 0, TSO will use the user specified PSERVIC. This allows different models 
of LU Type 0’s to be supported (e.g. 3278 Model 2 through 5, 3279 model 2 or 3 and graphics, etc.). 


2. If the device is an LU Type 1, TSO will honor user specified ASCII (alternate code indicator. This 
allows TSO to support both SNA 3767’s and NTO type TWX terminals both as LU Type I’s.). 


3. Ifthe device is an LU Type 2, TSO will honor user specified RUSIZES, PSERVIC, and ASCII 
(alternate code indicator). The ASCII indicator is used for APL, and this indicator is turned on 
whenever the terminal user presses the “APL ON” key at the terminal. The PSERVIC field allows for 
different models of LU Type 2’s to be supported (e.g. 3178 Model 2 or 3, 3290 in 3278 Model 2 through 
5 mode, etc.). 
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TSO/VTAM CONSIDERATIONS 


TSO DOES ISSUE ‘INQUIRE’ 

IF FMPROF =’02’ THEN LUO 

IF LUTYPE=’02’ THEN LU2 ELSE LU1 
BIND IS HARDCODED EXCEPT 


— LUO - USER PSERVIC USED 

— LU1 - USER SPECIFIED ASCII IS HONORED 

— LU2 - USER SPECIFIED RUSIZES USER SPECIFIED PSERVIC 
ASCII IS HONORED 


REFERENCES 


SC27-0584 ACF/VTAM PAIR VERSION 1 RELEASE 3 
-APPENDIX E 

SC27-0610 ACF/VTAM PAIR VERSION 2 RELEASE 1 
-APPENDIX E 

SC27-0610-2 ACF/VTAM V2R2 INSTALLATION AND 
RESOURCE DEFINITION-APPENDIX C 

$C23-0111 ACF/VTAM V3 INSTALLATION AND RESOURCE 
DEFINITION -APPENDIX C 
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NCCE V1 has a major requirement in the session initiation process. This requirement is that the Mode 
Table Entry name must be DSILGMOD. This means that you must have a different Mode Table for each 
unique device type (i.e. one table for SNA 3270s with a screen size of 1920, one table for a SNA 3270 with a 
screen size of 3440, etc.). 


NCCE does issue an ‘INQUIRE’ to determine and validate the session parameters. NCCF will change 
nothing in the BIND, and it will use the PSERVIC specified. 


The references given for NCCF show the Mode Table Entry parameters required by device type. 
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NCCF V1 CONSIDERATIONS 


MODE TABLE ENTRY NAME MUST BE ’DSILGMOD’ 
NCCF ISSUES ‘INQUIRE’ 
NCCF CHANGES NOTHING 
NCCF USES PSERVIC 
REFERENCES 
$C27-0430 NCCF INSTALLATION 


P, 42 (RELEASE 1) 
P. 51 (RELEASE 2) 
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NCCF V2 removes the NCCF V1 requirement for the Mode Table Entry name being DSILGMOD. This 
version of NCCF will accept any valid Mode Table Entry name, which eliminates unique Mode Tables 
because of the NCCE VI restriction for Mode Table Entry name. 


The remainder of the NCCF V2 support 1s consistent with NCCE VI. 


Foil 25 50 


NCCF V2 CONSIDERATIONS 


MODE TABLE ENTRY NAME IS USER DEFINED 
NCCF ISSUES ‘INQUIRE’ 

NCCF CHANGES NOTHING 

NCCF USES PSERVIC 

REFERENCES 


SC27-0660 NCCF V2 INSTALLATION AND 
RESOURCE DEFINITION 
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JES2/RJE also issues an ‘INQUIRE’ to determine the session parameters, but most of the BIND content is 
‘hardcoded’ or is built from parameters specified in SYS1.PARMLIB. 


This table shows that the only parts of the Mode Table Entry that are used are whether or not compression 
or compaction is allowable, and whether or not alternate code is supported. The rest of the BIND is 
determined by JES2. An excellent reference for all RJE Subsystems 1s the IBM 3770 SNA Installation 
Guide. 
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JES2/RJE CONSIDERATIONS 


e JES2 DOES ISSUE ‘INQUIRE’ 


e JES2 BUILDS BIND BASED ON 
PARAMETERS FROM SYS1.PARMLIB 


FIELD MODE TABLE JES2 BUILDS 
FMPROF NOT USED ‘03’ 
TSPROF NOT USED ‘03’ 
PRIPROT NO COMPR/COMPC  ‘B1’ 
COMPR OR COMPC ‘BS’ 
SECPROT NOT USED ‘AS’ 
COMPROT NO ALT CODE 1080" 
ALT CODE 1880" 
RUSIZES NOT USED 8585’ IF 
BUFSIZE = 256 
‘8686’ IF 
BUFSIZE = 512 


e REFERENCES 


GC30-3064 IBM 3770 SNA INSTALLATION GUIDE 

$C23-0003 SYSTEMS PROGRAMMER’S LIBRARY: 
NETWORK JOB ENTRY 
FACILITY FOR JES2 

SC23-0046 SYSTEMS PROGRAMMER’S LIBRARY: 
JES2 INSTALLATION, INITIALIZATION 
AND TUNING 

GG22-9373 NETWORK JOB ENTRY FORMATS 
AND PROTOCOLS FOR SYSTEM/37/0 
PROGRAM PRODUCTS 
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JES3, POWER/VS, and RES are all similar in their session initiation process. All will issue an ‘INQUIRE’ 
to determine the session parameters, and nothing is overridden. 
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JES3/POWER/RES CONSIDERATIONS 


© ALL DO ISSUE ‘INQUIRE’ 


e NOTHING IS OVERRIDDEN 


e REFERENCES 
GC28-6878 
SH12-5329 
GC28-0608 


$C23-0041 


GC30-3064 


OS/VS1 RES SYSTEMS PROGRAMMERS 
GUIDE 

VSE/POWER INSTALLATION AND 
OPERATIONS GUIDE 

OS/VS2 SYSTEMS PROGRAMMERS 
LIBRARY: JES3 

JES3 SYSTEM PROGRAMMING 
LIBRARY: INSTALLATION AND 

TUNING 

IBM 3770 SNA INSTALLATION GUIDE 
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MVS Bulk Data Transfer (BDT) is an application that transmits files between MVS systems. It issues an 
‘INQUIRE’ to determine the session parameters, but everything in the user supplied parameters is 
overridden, except the data encryption indicators. BDT uses format 0 negotiable BINDs. Negotiable BIND 
is used to set up some of the vanable parameters between the BDT applications. The values being 
negotiated are in the BIND User Data field, and are BDT operational control parameters which are defined 
in the BDTIN data set. The most important field that is negotiated is based on the BDT Data Buffer Size. 
This field is used to determine the actual RU size utilized between the BDT nodes (NOTE: BDT always 
sets the BIND RUSIZE to 256 for both the send and receive RU data length). The actual RU sizes sent 
between BDT nodes is the smaller of the two BDT nodes BUFSZ parameter. 


Some of the other considerations for BDT have to do with session pacing. BDT does not use SNA pacing 
because it uses its own pacing mechanisms. BDT supports multiple logical sessions (the number of which is 
defined by the BDT LU parameter) within a single SNA session. Each of these logical sessions (know as 
VLU’s or virtual LU’s) is paced independently. The pacing values used for this 1s defined by the BDT 
BUFNO parameter, which also controls when BDT checkpoints the data transmission. This is important 
because if the SNA session fails and is restarted, BDT will begin transmission based on the last checkpoint 
record. As such, this value should be carefully chosen. 


The last item with BDT has to do with data compression. This is an optional feature, and can increase the 
efficiency of the data transfer between BDT nodes. There is an impact on the CPU utilization in both the 
transmitting and receiving BDT nodes if compression is used. As such, there is a host CPU cycle versus 
network capacity issue that must be resolved relative to this facility. 
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MVS BULK DATA TRANSFER 
e BDT ISSUES ‘INQUIRE’ 
— ONLY ENCRYPTION INDICATOR IS USED 


— FORMAT OF NEGOTIABLE BIND USED 


FIELD MODE TABLE BDT BUILDS 
FMPROF NOT USED ‘04’ 
TSPROF NOT USED ‘07’ 
PRIPROT NOT USED ‘00’ 
SECPROT NOT USED ‘00° 
COMPROT NOT USED ‘0000’ 
RUSIZES* NOT USED 8585’ 
PACING NOT USED ‘00’ 
PSERVIC NOT USED ‘0000..’ 


— PARAMETERS FROM BDTIN DATA SET 
CONTROL BIND USER DATA FIELD 


FIELD BTD PARAMETER 
PASSWORD PASSWORD 
DATA BUFFER SIZE BUFSZ 

VLU PACING WINDOW BUFNO 


NUMBER OF VLU’S LU 
COMPRESSION OPTIONS 
SELECTABLE FEATURES 


— REFERENCES 


$C28-1314 BDT INITIALIZATION AND NETWORK DEFINITION 


* RUSIZE IS NOT USED. THE REAL RU SIZE IS THE SMALLER OF THE TWO BDT NODE’S BUFSZ 
VALUE, WHICH IS NEGOTIATED DURING BIND PROCESSING 
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ACF/TCAM V3 runs as an ACF/VTAM application program. This level of ACF/TCAM does issue the 
‘INQUIRE SESSPARM’ macro in the ACF/TCAM Logon exit routine. ACF/TCAM forces the BIND 
parameters to specify Immediate request mode and definite response mode chains are used. In addition, 

ACF/TCAM will validate the pacing parameters for single stage pacing. ACF/TCAM will insure that the 
primary send and secondary receive pacing values are the same, as long as single stage outbound pacing is 


being used. In a similar fashion, ACF/TCAM will insure that secondary send is the same as primary receive 


if inbound pacing is used. All other BIND parameters are unchanged by ACF/TCAM. 
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ACF/TCAM V3 


e TCAM ISSUES ‘INQUIRE’ 


© TCAM FORCES: 
FMPROF - 
IMMEDIATE REQUEST MODE 
DEFINITE RESPONSE CHAINS 


IF SINGLE STAGE OUTBOUND PACING - 
PRIMARY SEND = SECONDARY RECEIVE 


IF SINGLE STAGE INBOUND PACING - 
SECONDARY SEND = PRIMARY RECEIVE 


e ALL OTHER VALUES ARE UNCHANGED 


e REFERENCES 


$C30-3237  ACF/TCAM INSTALLATION, RESOURCE 
DEFINITION, AND CUSTOMIZATION GUIDE 

$C30-3236 ACF/TCAM INSTALLATION, RESOURCE 
DEFINITION, AND CUSTOMIZATION REFERENCE 
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The primary thing to remember when tuning or performing problem determination for session setup 
problems is that you must be working from a trace of the session initiation process. Instead of an external 
trace (such as ACF/VTAM IO trace), you can use NLDM to obtain session setup failure information. To 
obtain this data with NILDM, you must be using NLDM Release 3 in conjunction with ACF/VTAM V3 for 
same domain sessions. For cross domain or cross network session setup problems, any release of NLDM 
and ACF/VTAM can be used provided the CDRM sessions are being traced by NLDM. The one exception 
to this is if you are using a Subsystem that requires the SLU to be defined, the first step is to insure that it is 
at least defined. 


If you are attempting to tune your network or portions of it, a trace of the session can be very helpful. 
Again, NLLDM could be used to obtain the session parameters. For every session that NLDM is capturing 
session awareness data, the SNA BIND parameters are saved, and are available for online viewing by the 
NLDM operator. Am I using chaining and segmentation effectively? Are the maximum RU sizes optimum 
for the network? Is pacing being used effectively? Remember that some devices, such as SNA 3270 displays 
and printers in Data Stream Compatibility (DSC) mode, require no pacing at all. Other devices, such as 
SNA 3270 printers operating in SNA Character Set (SCS) mode (LU Type 1), do pequue pacing, but the 
pacing can be optimized to achieve maximum overlap on the printer. 


If you are trying to determine why a session didn’t get established the trace will show where the request was 
rejected. If the resource is cross domain or cross network, did the CDINIT and CDCINIT get positive 
response? If not the SNA Sense code should indicate the reason why. Did the Subsystem just issue a 
‘CLSDST’ rather than an “OPNDST” (i.e. there was no ‘BIND’ in the trace)? If that is the case then 
depending on the Subsystem, either the SLU was not defined or the session parameters were not agreeable. 
Did the BIND actually get sent but the device rejected it? If that is the case the component description 
manual or the device itself can point you to the portion of the BIND that was not acceptable (e.g. if an 
SNA 3776/3777 rejects the BIND, in the negative response user sense field will be a displacement into the 
BIND of the field that caused the rejection). 


It is not possible in a bulletin such as this to completely cover all aspects of the session initiation process. 
Hopefully, enough has been covered to get you started in the nght direction in the problem determination 
process. A basic understanding of what the subsystem does can be very time saving when trying to resolve 
the problem. 


A good rule of thumb is to always use a reference guide that is proven, like the ‘SNA Products Installation 


Guide’. The definitions provided in this manual may not be optimal for all conditions, but they will work 
and that 1s the main objective when starting out. 
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TUNING/PROBLEM DETERMINATION 


MUST TRACE SESSION INITIATION 
— USE IO TRACE OR NLDM 
TUNING 
— CHECK THE BIND BEING SENT 
— CHAINING/SEGMENTATION 
— MAXRU SIZES 
— PACING VALUES 
PROBLEM DETERMINATION 
— IS THE BIND BEING SENT 
— IS IT WHAT YOU WANTED 
— DEPENDING ON WHERE IT 
IS BEING REJECTED 
— COMPONENT DESCRIPTION MANUAL 
— SUBSYSTEM/VTAM DEFINITION 
REFERENCES 


GG24-1557 SNA PRODUCTS INSTALLATION GUIDE 
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You may use this form to communicate your comments about this publication, its organization, or subject 
matter, with the understanding that IBM may use or distribute whatever information you supply in any way 
it believes appropnate without incurring any obligation to you. 
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Comments: 
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IBM Corporation 
18100 Frederick Pike 
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